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ABSTRACT 



A method and system is provided for the preemptive goals 
based distribution of contact records. This method and 
system includes devices receiving contact records and pro- 
viding customer contacts to one or more agents, interfaced 
with the device is a distribution module including pools and 
queues. The distribution module places the contact records 
into the pools and transfers less than all of the contact 
records to the queues to allow for processing by the devices 
at peak efiSciency. The distribution module transfers the 
queues to the devices so that the device can place customer 
contact attempts. A goal module, associated with the distri- 
bution module, monitors the performance of the pools. The 
goal module modifies which queues the pools transfer 
contact records to based on the performance of the pools 
thereby allowing the contact records to be distributed in 
accordance with performance goals for the pools. 
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SYSTEM AND METHOD FOR PREEMPTIVE 
GOALS BASED ROUTING OF CONTACT 
RECORDS 

RELATED PATENT APPUCAnON 

[0001] This application is a coDtinuation-in-part of U.S. 
patent application Scr. No. 09/901,749 filed on Jul. 9, 2001 
and entitled "Method and System for Distributing Outbound 
Telephone Calls.** 

TECHNICAL FIELD OF THE INVENTION 

[0002] This invention relates to the field of telephony, 
computer networks, and customer relationship management, 
and more particularly to a system and method for preemp- 
tive goals based routing of contact records, 

BACKGROUND OF THE INVENTION 

[0003] Customer contact centers represent the front line 
for customer service, marketing operations, and debt col- 
lection for many businesses. Typical centers receive or make 
hundreds of telephone calls, emails, and Internet chat 
requests per day with the aid of automated telephony and 
Internet equipment. For instance, predictive dialers such as 
the MOSAIX Predictive Dialing System ("PDS") manufac- 
tured by Avaya Incorporated automatically dial outbound 
telephone calls to contact individuals and then transfer the 
contacted individuals to agents so the agent can talk with the 
individual. 

[0004] Devices such as dialing devices, email servers, chat 
servers, VOIP servers, telephony servers, and web servers 
allow agents to save time in contacting customers and 
receiving requests from customers. Dialing devices such as 
predictive dialers save time for the agent placing the call 
because the dialing device and not the agent dials the 
telephone number and agents' time is not wasted with 
unanswered calls or answering machines. Predictive dialers 
also spread the outbound telephone calls evenly among all 
the agents working from the dialing device so that the agents 
share the workload equally and no agents sit idle while 
others have too many telephone calls to place. Predictive 
dialers arc also a significant component of customer rela- 
tionship management (CRM) systems which extend the 
cfiGciency gained from predictive dialers to other contact 
channels such as email and live Internet chat. 

[0005] Many businesses are increasing their marketing 
efforts, customer service programs, and bad debt collection 
efforts by having multiple customer contact centers or call 
centers or multiple devices located at a single site to serve 
more customers. Typically, when businesses have multiple 
sites, the centers are located in different geographic locations 
which makes coordination of customer contact strategies 
difficult. 

[0006] Thus businesses generally manage call centers 
individually, with separate staffing, calling strategies, goals, 
and functions. Generally, a contact list is divided into as 
many parts as there are call centers or dialers with each call 
center receiving its own section of the calling list. Although 
this segmentation distributes work, coordination of strategy 
for outbound calling is difficuh since each call center is 
responsible for its own section of the calling list and has no 
knowledge of the other call centers' progression with their 



own calling lists. For instance, if a call center goes down and 
cannot make outbound telephone calls, the other call centers 
cannot typically address the downed call center's calling list 
goals and priorities because the other call centers do not 
have access to the calling list including the telephone 
numbers actually called. 

[0007] A similar problem occurs with a single call center 
having multiple CRM systems having multiple devices. 
Work load segmentation typically occurs at a host level, 
where each device is assigned a portion of the work load. A 
host downloads the segmented contact list to the individual 
dialing devices. If one device fails, the other devices do not 
know the status of the contacts in the failed device's 
segment. 

[0008] DifiGculties also arise in the routing of outbound 
calls, call records, or contact records to the agents in a single 
calling center or multiple calling centers. Typically when 
routing calls, a call center employs categorization and pri- 
oritization routing or load leveling routing. With categori- 
zation and prioritization routing, the calls are categorized 
and prioritized before being sent to the call centers. All of the 
available call records are organized into distinct groups or 
pools and each pool of caU records is prioritized according 
to a particular prioritizing scheme. A typical scheme often 
used at contact centers is to prioritize the inbound calls with 
the highest priority, live Internet chats second, outbound 
calls third, and email or other requests last. The agents are 
segregated into distinct teams and each team receives call 
records from a particular pool based on the prioritization of 
the call records. 

[0009] Load leveling routing of call records allows mul- 
tiple agent teams to work on the same group or pools of 
records whether the agents are located in the same call center 
or if the agents are located across multiple call centers. Load 
leveling routing eliminates the restriction of categorization 
and prioritization that requires distinct groups of records for 
agents not working from the same dialing device. This 
allows for the movement of call records between the agents 
and call centers. 

[0010] However, none of the above call record routing 
techniques adjusts the agent and pool workload based on the 
performance or the performance goals of the call record 
pools. Generally, if a call record pool is not maintaining a 
desired performance, manual intervention by a system 
administrator is required to adjust for the under performing 
call record pool. In order to address the under performing 
call record pool, agents must move from one team to another 
in order to have the ability to access call records from the 
under performing pool and thereby improve the call record 
pool performance. But this is a slow process that typically 
results in agent and call center downtime and often caimot 
be made quickly enough to respond to current call record 
pool performance. 

[OOU] In addition, such manual intervention decisions to 
correct under performing call records pools typically require 
guess work arKl making decisions without considering all the 
available options and the effect on the other call record 
pools. The system administrator must guess as to the effects 
on the other call record pools when agents are moved from 
pools maintaining or achieving performance requirements to 
under performing pools. If agent moves are made incor- 
rectly, then additional pools may start under performing due 
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to the agents that were moved to the under performing pool. 
Therefore the performance of the call record pools requires 
constant supervision to ensure that by the end of the calling 
day the performance requirements for the highest priority 
pools are satisfied. 

SUMMARY OF THE INVENTION 

[0012] Therefore, a need has arisen for a system and 
method that distributes contact records based on the perfor- 
mance of the pools of contact records. 

[0013] A further need has arisen for a system and method 
that automatically monitors the performance of the pools 
and automatically adjusts the distribution of contact records 
based on the performance of the pools. 

[0014] In accordance with the present invention, a system 
and method for distributing contact records utilizing goals 
based routing is provided which substantially eliminates or 
reduces disadvantages and problems associated with previ- 
ously developed systems and methods for distributing con- 
tact records. A goal module monitors the performance of one 
or more pools of contact records and automatically modifies 
the distribution of the contact records from the pools based 
on the performance of each pool. 

[0015] In accordance with one aspect of the present inven- 
tion, distribution of contact records utilizing goals based 
routing is accomplished by a distribution module interfaced 
with a plurality of devices. The distribution module includes 
a plurality of pools and a plurality of queues. The distribu- 
tion module places contact records into the pools, transfers 
less than all of the contact records to the queues from the 
pools, and transfers the queues to the devices. Associated 
with the distribution module is a goal module. The goal 
modxile monitors the performance of each pool and modifies 
which queues the pools transfer contact records to based 
upon the performance of the pools. 

[0016] In one embodiment, the goal module defines one or 
more levels of effort for each queue. The levels of effort 
determine the percentage of contact records that transfers 
from a pool to a particular queue. The goal module also 
determines a goal for each pool that reflects the performance 
of the pool and prioritizes the pools relative to each other. As 
the agents access the contact records from the queues, the 
goal module monitors the performance of the pools by 
calculating a goal status for each pool- The goal module uses 
the goal status to determine a goal state for each pool. The 
goal state indicates whether a pool is satisfying the goal. 
Based upon the goal states for each pool, the goal module 
modifies which queues the pools transfer contact records to 
by transferring the levels of effort between the pools and the 
queues. 

[0017] In an altemate embodiment, the goal states and one 
or more goal strategies allow for the optimization of the 
transfer of contact records fi'om the pools to the queues and 
determine how the goal module modifies which queues the 
pools transfer contact records to. The goal strategies control 
how levels of effort between the pools and queues are 
transferred when a pool is not satisfying the goal. A goal 
strategy may require the transfer of levels of effort to pools 
not satisfying their goals or the transfer of levels of effort 
away from pools not satisfying the goal. The goal module 
transfers leveb of effort in accordance with the goal strat- 



egies so that pools having the highest priority maintain or 
achieve the goak throughout the day. 

[0018] The present invention provides a number of impor- 
tant technical advantages. One important technical advan- 
tage is the distribution of contact records based on the 
performance of the pools. The ability to distribute contact 
records based on the performance of the pools of contact 
records allows a call center to operate more efificiendy 
because the call center recognizes when a pool is not 
sufficiently performing and redistributes the contact record 
workload to allow for more efficient operation thereby 
allowing higher priority pools to satisfy performance 
requirements. 

[0019] Another important technical advantage of the 
present invention is the distribution of contact records based 
on the performance of the pools without manual interven- 
tion. The goal module monitors the performance of each 
pool and determines whether a pool is ahead, at, or behind 
the goal. When a pool is not satisfying a goal, the goal 
module automatically takes action to modify how the pools 
transfer contact records to so that the highest priority pools 
achieve or maintain the goals. Therefore, no manual inter- 
vention is required and pools are not adversely affected by 
the changes. In addition, because no manual intervention is 
required, there is reduced agent or device downtime when 
the goal module distributes the contact records based upon 
the performance of the pools. 

[0020] Another important technical advantage of the 
present invention is the ability to quickly respond to current 
pool performance levels. Because the goal module con- 
stantly monitors the performance of the pools, the goal 
module may instandy react to any change in the perfor- 
mance of the pools throughout the day. And because the goal 
module monitors the performance of all the pools and has 
the goal states for every pool, when the goal module 
modifies the distribution of contact records, the goal module 
takes into account the effects of the modification on the goals 
for all of the pools so that the highest priority pools achieve 
or maintain the goals. Therefore, the guess work in distrib- 
uting contact records based on the performance of the pools 
is reduced and there are no unexpected results at the end of 
the day. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0021] For a more complete understanding of the present 
invention and the advantages thereof, reference is now made 
to the following description taken in conjunction with the 
accompanying drawings in which like reference numbers 
indicate like features, and wherein: 

[0022] FIG. 1 depicts a block diagram of plural dialing 
devices interfaced with a distribution module; 

[0023] FIG. 2 illustrates a block diagram of another 
embodiment of the present invention employing two distri- 
bution modules; 

[0024] FIG. 3 depicts a flow diagram of a method for 
distribution outbound telephone calls; 

[0025] FIGS. 4a and 4fc illustrate a flow diagram for the 
population of the pools and queues with call records; 

[0026] FIG. 5 depicts a flow diagram of a method for 
goals based routing of contact records employing a meet- 
goals goal strategy; and 
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[0027] FIG. 6 illustrates a flow diagram of a method for 
goals based routing of contact records employing an exceed- 
goals goal strategy. 

DETAILED DESCRIPTION OF THE 
INVENTION 

[0028] Preferred embodiments of the present invention are 
illustrated in the figures, like numeral being used to refer like 
and conesponding parts of the various drawings. 

[0029] Under previous systems and methods for routing 
contact records, the redistribution of contact records among 
the devices and agents based upon the performance of the of 
the different pools of contact records required manual inter- 
vention often involving guesswork as to the effects of 
performance based changes, the shutting down of the 
devices, starting a new job on the device, or moving agents 
between the devices. The goal module of the present inven- 
tion allows for the routing of contact records across one or 
more than one device based on the performance of the 
individual pools of contact records quickly and without 
manual intervention. The goals based routing of contact 
records allows for dynamically modifying the distribution of 
contact records based on the performance of the pools of 
contact records throughout the day without manual inter- 
vention, down time, and guesswork. 

[0030] The present invention allows for the routing and 
distribution of contact records among a plurality of devices 
and agents based upon the performance of the different pools 
of contact records. Contact records include such customer 
contacts as outbound telephone calls, inbound telephone 
calls, call records, emails^ Internet cbat requests, online chat 
requests, and any other appropriate form of customer con- 
tact. Devices include such call center or contact center 
devices as dialing devices including predictive dialers, emaU 
servers, Internet chat servers, VOIP servers, telephony serv- 
ers, web servers, and any other appropriate call center or 
contact center devices. In the figures below, reference is 
made to call records and dialing devices but the present 
invention equally applies to the other types of contact 
records and devices listed above. 

[0031] FIG. 1 depicts a block diagram for an outbound 
distribution system 100 for distributing outbound telephone 
calls employing goals based routing. A distribution module 
102 interfaces with a first call center 104a and a second call 
center 104/2. System 100 allows call centers 104fl and 104/1 
to operate as a single group of resources rather than two 
decentralized units, with distribution module 102 controlling 
the strategy, workload, and calling efforts for call centers 
104 from a single, central location. In alternative embodi- 
ments, distribution module 102 interfaces with multiple 
dialing devices at one or more call centers, or one diahng 
device located in one call center. 

[0032] Call centers 104 are geographically distributed, 
each having one or more dialing devices that place telephone 
calls using information in the call records. Distribution 
module 102 operates on a SOLARIS, Linux, or an any other 
appropriate operating system server and communicates with 
call centers 104 via standardized communications links such 
as Ethernet, the Internet with protocols such as FTP, 
CORBA, API, and sockets over TCP/IP, asynchronous trans- 
fer mode ("ATM"), or any other appropriate communication 
Unk. 



[0033] Call centers 104 each have one or more dialing 
devices 108. Dialing devices 108 are predictive dialers such 
as the MOSAIX PDS manufactured by Avaya Incorporated 
or other appropriate predictive dialers. In the embodiment 
shown in flG. 1, interfaced to dialing device 108a in call 
center 104a are three agents UOa, 1106, and 110c with 
dialing device 108/z of call center 104/i also having three 
agents llOrf, UOe, and IKy' interfaced to it. Agents 110 are 
workstations where operators or agents ^eak to the indi- 
viduals, chat with individuals online, complete emails to, or 
otherwise contact individuals who are contacted by dialing 
devices 108. 

[0034] Dialing device 108 dials telephone numbers 
extracted from the call records. If an individual answers the 
telephone, dialing device 108 transfers the telephone call to 
one of agents 110 so that the agent can speak with the 
individual. Dialing devices 108 therefore improve telephone 
calling efficiency by dialing the telephone number and 
transferring the call to an agent only if an individual answers 
the telephone. 

[0035] System 100 functions by first having distribution 
module 102 acquire the call records that dialing devices 108 
will call. There are several different ways that distribution 
module 102 acquires the call records. 

[0036] For instance, host 112, which is associated with 
dialing devices 108, stores raw call records. The raw call 
records contain information including telephone number, 
account number, individual name and address, and any other 
appropriate personal information. For example, a raw call 
record for Joe Smith includes Joe Smith's telephone number, 
mailing address, account status, account number, account 
passwords, gender, marital status, number of children, 
employment status, and yearly income. 

[0037] Host 112 transfers the raw call records for that day 
along path 114a to call center 104a and dialing device 108fl 
and along path 114b to call center 104/i and dialing device 
108/j. Distribution module 102 contacts dialing device 108a 
within call center 104a via path 116a and dialing device 
108/1 within call center 104n via path 1166. Distribution 
module 102 downloads from dialing devices 108 to call 
record database 118 the call records. The call records may 
contain some but not all of the information from the raw call 
records. Downloading less than all of the information from 
the raw call records saves bandwidth and allows for efficient 
operation of distribution module 102 because it handles 
smaller amounts of data. For instance, distribution module 
102 downloads as the call record an individual's name, 
telephone number, and account number. So the call record 
for Joe Smith contains Joe Smith's name, his telephone 
number, and accoimt nxunber. 

[0038] In an alternative embodiment, host 112 stores the 
raw call records. Instead of transferring the raw call records 
to dialing devices 108, distribution module 102 downloads 
the call records from host 112 to call record database 118 via 
path 120. 

[0039] Alternatively, dialing devices 108 store the raw call 
records. Therefore, distribution module 102 contacts call 
center 104a and dialing device 108a via path 116a and call 
center 104/1 and dialing device 108/i via path 116b to 
download the call records to call record database 118. 

[0040] Scheduling module 122 operates to develop and 
provide optimal calling strategies for the call records includ- 
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ing resource optiniizatioD, automated statistical modeling 
and flexible strategy management. For instance, one such 
scheduling module 122 is described in U.S. Pat. No. 5,802, 
161, entitled "Method and System for Optimized Schedul- 
ing- "issued Sep. 1, 1998, and is hereby incorporated by 
reference. 

[0041] The integration of sched\ding module 122 is not 
required for the operation of distribution module 102 but it 
affects how distribution module 102 downloads the call 
records and what information is contained in the call 
records. For instance, host 112 transfers the raw call records 
to call center 104a and dialing device 108a via path 114a 
and call center 104/i and dialing device 108« via path 114b, 
Scheduling module 122 downloads from dialing device 
108a in call center 104a via path 124a and from dialing 
device lOSn in call center 104/1 via path 124b the raw call 
records. Scheduling module 122 develops call schedules for 
the raw call records. Distribution module 102 downloads the 
call records including the call schedule from scheduling 
module 122 via path 124c and stores the call records in call 
record database 118. 

[0042] Alternative embodiments also employ scheduling 
module 122 in the delivery of call records to distribution 
module 102. Scheduling module 122 downloads the raw call 
records from host 112 via path 126. As before, scheduling 
module 122 adds call schedules to the raw call records 
before distribution module 102 downloads the call records 
from scheduling module 122 via path 124c to call record 
database 118. 

[0043] Once distribution module 102 stores the call 
records in call record database 118, distribution module 102 
organizes and transfers the call records from call record 
database 118 to pools 128, which are interfaced with distri- 
bution modiile 102. The pools are sets of callable call 
records specified by distribution module 102. Each pool 128 
represents a specific and ordered group of call records. In the 
embodiment shown in FIG. 1, there are three pools 128a, 
1286, and 128c. In alternative embodiments there can be 
more than three or less than three pools. 

[0044] Distribution module 102 then transfers less than all 
of the caU records from pools 128 to queues 130. Interfaced 
with pools 128 are queues 130a, 130i), 130c, and 130rf. A 
queue is a set of rules for selecting call records from pools 
having the necessary and sufficient information describing 
the exact method of transferring call records to dialing 
devices 108 and any call records assigned to but not yet 
transfened to dialing devices 108 for dialing devices 108 to 
call. Distribution module 102 attaches each queue 130 to a 
particular dialing device 108 and monitors each dialing 
device. As necessary, distribution module 102 transfers call 
records from pools 128 in accordance with the configuration 
of queues 130 which includes selection rules, time of day, 
lime of week, number of calls completed, and number of call 
records sent. Queues 130 then transfer the call records to 
their assigned dialing devices 108. For instance, distribution 
module 102 transfers call records according to the configu- 
ration of queues 130a and 130b to dialing device 108a of 
call center 104a and according to the configuration of 
queues 130c and 13^0d to dialing device 108n of call center 
104rt. 

[0045] In addition, each queue 130 is associated with a 
single campaign for the dialing device to which it is 



assigned. A campaign is an outbound job calling on dialing 
device 108 that can receive additional call records for calling 
while the outbound calling job is active. Normally, a cam- 
paign on dialing device 108 continues to run until manually 
stopped or when it runs out of call records to dial. 

[0046] Pools 128 can satisfy transfer requests for call 
records for one or more than one queue 130. For example, 
pool 128a transfers call records to queue 130a, pool 1286 
transfers call records to queues 1306 and 130c, and pool 
128c transfers call records to queue 130d. In addition, 
distribution module 102 can change the queues which 
request call records from pools 128 throughout the day and 
in the middle of outbound calling campaigns. For instance, 
if dialing device 108n located in call center 104rt calls all the 
call records in pool 128c, then distribution module 102 can 
request that pools 128a and 1286 transfer call records to 
queue 130t/. 

[0047] Distribution module 102 transfers the call records 
to pools 128, transfers less than all of the call records from 
pook 128 to queues 130, and transfers queues 130 to dialing 
devices 108 before dialing devices 108 begin their daily 
calling routines. At the beginning of the day, distribution 
module 102 transfers enough call records from pools 128 to 
queues 130 to allow for dialing devices 108 to place calls for 
fifteen, thirty, sixty minutes, or an appropriate amount of 
time to place calls. Distribution module 102 monitors the 
calls placed by dialing devices 108 as well as the number of 
call records remaining to be called to determine how busy 
dialing devices 108 are and when and how many additional 
call records to transfer from pools 128 to queues 130. The 
monitoring of queues 130 and the transferring of additional 
call records from pools 128 to queues 130 allows for 
real-time movement of call records from distribution module 
102 to dialing devices 108 throughout the day. For instance, 
as soon as dialing device 108a is about to finish calling the 
call records in the campaign assigned to queue 130fl, dis- 
tribution module 102 transfers additional call records from 
pool 128a to queue 130a so that dialing device 108a 
maintains a steady and level flow of work. 

[0048] Dialing devices 108 also track the call attempt 
results of every call placed by dialing devices 108. The call 
attempt results include whether or not a call resulted in a 
right party contact, a wrong party contact, no answer, or an 
answering machine. For example, the objective of a call 
record for Joe Smith is to talk with Joe Smith. If agent 110 
speaks with Joe Smith, that is a right party contact and a 
successful call attempt result. If Joe's babysitter answers the 
phone and Joe is not home, that is a wrong parly contact and 
an unsuccessful call attempt result. If no one answers the 
phone or an answering machine answers the phone, that is 
an unsuccessful call attempt result since the desired party 
was not contacted. Therefore throughout the day, distribu- 
tion module 102 queries dialing devices 108 for call attempt 
results and uploads the call attempts results. If a call attempt 
result is unsuccessful, then distribution module 102 updates 
the call record in pools 128 so that a dialing device 108 may 
call the call record again at a later time in the day. 

[0049] An advantage to system 100 is that distribution 
module 102 controls the transfer of the call records which 
results in a level work flow for dialing devices 108. To 
enable better work flow control, queues 130 include selec- 
tion rules that determine how distribution module 102 
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transfers call records from pools 128 to queues 130. The 
selection rules allow for the optimization of the transfer of 
call records from pools 128 to queues 130 and include 
priority rules, pcrccatage rules, quotas, queuing theory rules, 
or any other appropriate rules for optimizing the transfer of 
call records from pools 128 to queues 130. The selection 
rules can be modified on an as needed basis. 

[0050] Priority rules result in distribution module 102 
transferring call records from pools 128 to queues 130 based 
upon an assigned priority for each pool 128. For example, 
queue 130fl receives call records from pools 128fl and 1286 
with pool 128a having priority over pool 128b. Queue 1306 
receives call records from pools 128fl and 1286 with pool 
1286 having priority over pool 128^2. Assume that pool 128a 
arrives at 8:00AM while pool 1286 arrives at 9:00AM. 
Initially, both queues 130a and 1306 receive call records 
from pool 128fl. At 9:00AM when pool 1286 arrives, queue 
130a continues to receive call records from pool 128a while 
queue 1306 receives call records from pool 1286. 

[0051] Percentage rules result in distribution module 102 
simultaneously transferring call records from pools 128 to 
queues 130. For example, queue 130c has a percentage 
configuration with pools 1286 and 128c and queue \30d has 
a percentage configuration with pools 1286 and 128c. In this 
configuration, queue 130c and 130d receive call records 
simultaneously from pools 1286 and 128c. With pool 1286 
arriving at 8:00AM and pool 128c arriving at 9:00AM, at 
8:00AM both queues 130c and 130d receive call records 
from pool 1286. At 9:00AM, queues 130c and 130J alter- 
natively receive call records from pools 1286 and 128c. The 
percentages are variable for instance so that queue 130c 
receives 80% of its call records from pool 1286 and 20% of 
its call records from pool 128c while queue 130d receives 
60% of its call records from pool 1286 and 40% of its call 
records from pool 128c. 

[0052] The selection rules can also incorporate the execu- 
tion of an optimization module which will determine the 
optimal mix of call records from each of the available pools 
128 based on the optimization constraints and the number of 
call records needed at the current time. 

[0053] The selection rules can also incorporate pool quo- 
tas whidi are limits set on each pool controlling a maximum 
activity level such as ntmiber of records transferred, number 
of successful call attempts, and other appropriate indicators 
of call record activity. When distribution module 102 trans- 
fers call records to pools 128, distribution module 102 can 
also set quotas on how many call records dialing devices 108 
will call from pools 128. In the percentage rule example 
above, distribution module 102 can place a quota on pool 
1286. When dialing devices 108 satisfy the quota for pool 
1286, queues 130c and 130d no longer receive call records 
from pool 1286 and only receive call records from pool 
128c. 

[0054] The selection rules can also be a combination of the 
percentage rules and the priority rules. For example, queue 
1306 receives call records from all three pools 128a, 1286, 
and 128c. Queue 1306 receives call records from pool 1286 
until dialing device 108a calls all the call records in pool 
1286. At that time, queue 1306 then alternately receives call 
records from pools 128a and 128c. As with the percentage 
rules above, queue 1306 can receive call records from pools 
128a and 128c in any percentage breakdown. Therefore, 



pool 1286 has priority over pools 128a and 128c while pools 
128a and 128c transfer call records using percentage rules. 

[0055] In addition, these selection rules allow for skills- 
based routing between pools 128. For example, distribution 
module 102 allows pool 128a to initially transfer call 
records to queue 130a and pool 128c to initially transfer call 
records to queue I30d. If pool 128c becomes depleted and 
has no more call records to transfer to queue 130d, then pool 
128a can begin transferring call records to both queues 130a 
and 130^. This allows distribution module 102 to transfer 
call records for easy to moderate difficulty customers to the 
best agents while the less skilled agents work the more 
difficult customers. And once the easy to moderate difi&culty 
customers call records are depleted, the best agents can 
begin working the more difficult customer call records. 

[0056] In addition, distribution module 102 may also route 
call records to dialing devices 108 and agents 110 based on 
the performance of pools 128. Routing the call records based 
on the performance of pools 128 allows distribution module 
102 to make modifications so that pools 128 having a higher 
priority are not under-performing. Goal module 103, asso- 
ciated with distribution module 102 and pools 128, monitors 
the performance of pools 128. To monitor the performance 
of pools 128, either a user of system 100 or goal module 103 
defines a performance metric for eadi pool 128. Once the 
performance metric is defined, goal module 103 applies the 
performance metric to pools 128. The performance metric is 
what goal module 103 uses to measure the performance of 
pools 128. For example, the performance metric for pool 
128a may be the number of right party contacts while the 
performance metric for pool 1286 is the number of accounts 
attempts and the performance metric for pool 128c is the 
number of call records attempted. Each pool 128 may have 
a difBerent performance metric or pools 128 may have the 
same performance metric. In addition, each of the pools 128 
may have more than one performance metric. For instance, 
pool 128a may have both a performance metric for the 
number of right party contacts and for the number of total 
accounts attempted. 

[0057] Once goal module 103 has determined a perfor- 
mance metric for each pool 128, goal module 103 defines a 
goal for eadi pool 128. The goal can be either an absolute 
goal or a goal set relative to aU the other pools 128. An 
absolute goal is a goal tied solely to the performance of the 
particular pool 128 while a relative goal is tied to the 
performance of all pools 128. In addition, the goal is related 
to the selected performance metric. For instance, pool 128a 
having a performance metric of number of right party 
contacts may have a goal of fifty right party contacts while 
pool 128c having a performance metric of number of call 
records attempted has a goal of one hundred call records 
attempted. 

[0058] If a pool 128 has more than one performance 
metric, then the pool 128 will have a goal for each perfor- 
mance metric. For example, if pool 128a has a performance 
metric for number of right party contacts and for-total 
number of accounts attempted, pool 128a may have a goal 
of 80 right parly contacts and 200 accounts attempted. In 
addition, a pool 128 may also have a combination of goals 
where there pool 128 only needs to satisfy one of the goals. 
For instance, pool 1286 may have a goal of 75 right party 
contacts or 200 accounts attempted and as long as pool 1286 
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has at least 75 right party contacts or 200 accounts 
attempted, pool 12Sb is considered to be satisfying its goal 
and experiencing satisfactory performance. 

[0059] The goals may also be end of day goals, mid-day 
goals, and rate based goals. End of day goals are goals 
calculated based on the performance of a pool 128 at the end 
of the day and include such goals as total number of call 
records attempted and number of right party contacts. Mid- 
day goals are similar to end of day goals but are calculated 
based on the time of day. For example, pool 12Sa may have 
a mid -day goal of twenty-five right party contacts by noon. 
Rate based goals are calculated as a rate of the total calls. For 
instance, if pool 12Ha has a performance metric of right 
party contact rate, a rate based goal may be 15% of all the 
call records from pool l2Sa should result in a right party 
contact 

[0060] Similar to the selection rules, goal module 103 
defines or constrains levels of effort for each queue 130. The 
levels of effort detail the percentage of call records that 
transfer from a particular pool 128 to a particular queue 130. 
The levels of effort are stored in an effort map associated 
with goal module 103. Table 1 shows an example effort map 
for system 100. An examination of the effort map shown in 
Table 1 reveals that queue 1 (queue 130a) has a level of 
effort of 100% to pool 1 (pool HHa) meaning queue 130a 
receives all of its call records from pool 128a. Queue 2 
(queue 130i>) has a level of effort of 100% to pool 2 (pool 
128^) meaning queue 130b receives 100% of its call records 
from pool 1286. Queue 3 (queue 130c) has a level of effort 
of 100% to pool 2 (pool 12Sb) meaning queue 130c receives 
100% of its call records from pool 128iE>. Queue 4 (queue 
130^0 has a level of effort of 100% to pool 3 (pool 128c) 
meaning that queue 130£/ receives 100% of its call records 
from pool 128c. Therefore, 100% of the caU records in pool 
128a transfer to queue 130a, the call records in pool 1286 
transfer equally to queues 1306 and 130c, and 100% of the 
call records in pool 128c transfer to queue 130d, 



TABLE 1 





Example 
Fool 1 


ES^ort Map 
Pool 2 


Pool 3 


Queue 1 


100% 


0% 


0% 


Queue 2 


0% 


100% 


0% 


Queue 3 


0% 


100% 


0% 


Queue 4 


0% 


0% 


100% 



[0061] As pools 128 begin to transfer call records to 
queues 130 and agents 110 access the call records, goal 
module 103 calculates a goal status for each pool 128. The 
goal status can be defined as either the absolute difference 
between the actual metric and the goal or the percentage that 
a pool 128 is either ahead or behind its goal. For instance, 
if each pool 128 has a goal of fifty right party contacts and 
pool 128a has forty-five right party contacts, pool 1286 has 
forty-eight right party contracts, and pool 128c has sixty 
right party contacts, then pool 128a has a goal status of 
-10%, pool 1286 has a goal status of -4%, and pool 128c 
has a goal status of +20% for percentage based goals. Pool 
128a has a goal status of -5, pool 1286 has a goal status of 
-2 and pool 128c has a goal status of +10 for absolute 
difference based goals. 



[0062] Goal module 103 uses the goal status for each pool 
128 to determine a goal state for each pool 128. Pools 128 
will have a goal state for each goal. An example definition 
of goals states would include the designation of ahead of 
goal, at goal, or behind goal. Goal module 103 or a user of 
system of 100 determines what thresholds define each of the 
available goal states. For example, if the goal states have 
been defined as ahead of goal, at goal, or behind goal, then 
a goal status of +10% and above may be ahead of goal, a 
goal status between +10% and -5% may be at goal, and a 
goal status of -5% and below may be behind goal. Given 
these threshold percentages and the goal status for pools 
128, pool 128a has a gpal state of behind goal (-10%), pool 
1286 has a goal state of at goal (-4%), and pool 128c has a 
goal state of ahead of goal (+20%). Any pool 128 that has 
a goal state of behind goal is said to be an under-performing 
pool and therefore experience unsatisfactory performance. 

[0063] Similar to the pool quotas described above, goal 
module 103 also identifies and defines a final goal for each 
pool 128. A user of system 100 may also define the final 
goals for each of the pools 128. When a pool 128 satisfies its 
final goal, that pool 128 is no longer active and all the queues 
130 that were receiving call records from that pool 128 now 
receive call records from the other pools 128 that have not 
satisfied their final goals. For instance, pool 128a-128c each 
have a final goal of eighty right party contacts. At 3:00PM, 
pool 128a achieves eighty right party contacts. Because pool 
128a has achieved its final goal, it becomes inactive and the 
call records from pool 128a are no longer transferred to 
queue 130a. To prevent queue 130a and agents 110 who 
access call records firom queue 130a from becoming inac- 
tive, goal module 103 modifies which queues 130 pools 
1286 and 128c transfer call records to by allowing pools 
1286 and 128c to transfer call records to queue 130a. Since 
pools 1286 and 128c have not reached their final goals, they 
are still active and queues 130 and agents 110 who were 
receiving call records from pool 128a now receive call 
records from pools 1286 and 128c. 

[0064] Before distribution module 102 begins to transfer 
queues 130 containing the call records to dialing devices 
108, goal module 103 prioritizes pools 128 relative to each 
other. Certain pools 128 may contain call records that are of 
a higher priority than other pools 128. For example, pool 
128a may contain call records for customers who have 
previously purchased products, pool 1286 may contain call 
records for customers who have never-purchased products, 
and pool 128c may contain call records for customers who 
are delinquent in paying for products previously purchased. 
Since a company's highest priority may be to collect the 
money it is owed, goal module 103 rates pool 128c with the 
highest priority while pool 128a has the second highest 
priority since it contains call records for customers with 
whom there is a previous relationship. Pool 1286 has the 
lowest priority since it contains call records for potential 
customers. The prioritization of pools 128 enables goal 
module 103 to adjust the workload of agents 110 so that 
pools 128 having the highest priority achieve and maintain 
their goals throughout the day. 

[0065] Goal module 103 modifies the distribution of call 
records using the goals of pools 128 by modifying which 
queues 130 pools 128 transfer call records to based on the 
performance and prioritization of pools 128. Goal module 
103 modifies which queues 130 pools 128 transfer call 
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records to by adjusting or transferring the levels of effort 
between pools 128 and queues 130. For example, pool 128a 
is of a higher priority than pool 128c and pool 128a is behind 
goal. Using the effort map shown in Table 1, queue 130a 
receives 100% of its call records from pool 128fl and queue 
130rf receives 100% of its call records from pool 128c. Since 
pool 128a is of a higher priority, goal module 103 transfers 
level of effort from pool 128c to pool 128a so that queue 
130rf receives 50% of its call records from pool 128c and 
50% of its call records frum pool 128a while queue 130a 
still receives 100% of its call records from pool 128a. The 
example effort map shown in Table 2 illustrates which 
queues 130 pools 128 supply call records to after goal 
module 103 modifies the distribution of call records. Trans- 
ferring some of the level of effort from pool 128c to pool 
128a allows agents 110 who work queue 130rf to work call 
records from pool 128a and thereby increase the number of 
agents 110 accessing call records from pool 128a so that 
pool 128a may satisfy its goal. 



TABLE 2 





Example 
Pool 1 


Effort MaD 
Pool 2 


Pool 3 


Queue 1 


100% 


0% 


0% 


Queue 2 


0% 


100% 


0% 


Queue 3 


0% 


100% 


0% 


Queue 4 


50% 


0% 


50% 



[0066] To aid in the distribution of call records based on 
the performance of pools 128, goal module 103 employs one 
or more goal strategies. The goal strategies allow for the 
optimization of the transfer of call records from pools 128 to 
queues 130 and help to determine how goal module 103 
transfers the levels of effort between pools 128 and queues 
130. There are different goal strategies that goal module 103 
may implement when distributing the call records based on 
the performance of pools 128. Goal module 103 may auto- 
matically select the goal strategy based upon the call records 
or a user of system of 100 may select an appropriate goal 
strategy. 

[0067] One goal strategy is a meet-goals strategy. With the 
meet-goals strategy, goal modide 103 transfers levels of 
effort to pools 128 that are not meeting their goals (a goal 
state of behind goal) and therefore are experiencing unsat- 
isfactory performance. For example, if pool 128a is behind 
goal and pool 128& is ahead of goal, goal module 103 
transfers levels of effort from pool 1286 to pool 128a so that 
queues 130b and 130c also receive call records from pool 
128a. A number of right party contacts performance metric 
is a performance metric that might be managed with the 
meet-goals goal strategy. 

[0068] Another goal strategy is an exceed-goals strategy. 
With the exceed-goals strategy, goal module 103 transfers 
levels of effort away from pools 128 that are not meeting 
their goals (a goal state of behind goal) and therefore have 
unsatisfactory performance. For instance, if pool 1286 is 
behind goal and pool 128c is at goal, goal module 103 
transfers levels of effort from pool 1286 to pool 128c so that 
queues 1306 and 130c begin to receive call records from 
pool 128c. A right party contact rate performance metric is 
a performance metric that might be managed using the 
exceed-goals goal strategy. 



[0069] To insure that lower priority pools 128 do not 
become neglected when goal module 103 routes call records 
based on the performance of pools 128, goal module 103 
sets preemptive limits on how much level of effort may be 
transferred away from pools 128. These preemptive limits 
are stored in routing tables of which each pool 128 has its 
own routing table stored in goal module 103. An exemplary 
routing table for pool 128a is shown in Table 3. In the 
example routing table of Table 3, if pool 128a is ahead of 
goal, then pool 128a is willing to forego 75% of its total 
level of effort to pools 128 that are at a higher priority that 
need additional levels of effort. Pool 128a is willing to 
forego 50% of its total level of effort to pools 128 that are 
at the same priority that need effort if pool 128a is ahead of 
goal. Pool 128a is willing to give up 25% of its total level 
of effort to pools 128 that are of lower priority if needed if 
pool 128a is ahead of goal. The percentages are then set at 
40%, 25% and 15% if pool 128a is currenUy at goal. If pool 
128a is behind goal, pool 128a will only give up 25% of its 
level of effort and only to a pool 128 of higher priority. Each 
pool 128 has its own routing table and the percentages may 
vary depending on the nimiber of pools, the number of call 
records, or any other appropriate factors. 



TABLE 3 





Example Routing T^ble 






Ahead 


At 


Behind 


Higher Priority 
Same Priority 
Lower Priority 


75% 
50% 
25% 


40% 
25% 
15% 


25% 
0% 
0% 



[0070] In an alternate embodiment, the goal slates and one 
or more goal strategies are inputs to and determine the 
objective functions and the constraints for an optimized 
solution to the routing determination problem. The goal 
strategies control how constraints on the levels of effort 
between pools 128 and queues 130 are relaxed or tightened 
when a pool 128 is not satisfying the goal. A goal strategy 
may allow for the transfer of higher levels of effort to pools 
128 not satisfying their goals or allow for the transfer of 
higher levels of effort away from pools 128 not satisfying the 
goal. The goal module adjusts the level of effort constraints 
in accordance with the goal strategies so that pools 128 
having the highest priority maintain or achieve the goals 
throughout the day. 

[0071] la case of a communication, dialing device, or call 
center outage, system 100 employs contingency modules 
132 for each dialing device 108. Contingency modiiles 132 
are associated with dialing devices 108. Contingency mod- 
ules 132 secure the call records within their respective 
dialing devices 108 in case of an outage. Before distribution 
module 102 transfers the call records to pools 128, distri- 
bution module 102 creates call record accounts for dialing 
devices 108, locks the call record accounts to dialing devices 
108, creates a contingency download file, and stores the 
contingency download file in contingency modules 132. 
Distribution module 102 updates the contingency download 
file with call attempt results which prevents dialing devices 
108 firom calling call records already successfully called. 

[0072] Users of system 100 conUx)l the functionality of 
distribution module 102 and goal module 103 through a user 
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interface. The user interface is shown as online interface 134 
in FIG. 1 but can be any appropriate type of user interface. 
Online interface 134 is a graphical user, platform-indepen- 
dent, password-protected World Wide Web ("WWW") 
browser-based interface. Users use online interface 134 to 
control the settings for distribution module 102 inchiding 
goal module 103 including application of the selection rules, 
number of pools, and number of call records to initially 
transfer to the queues, generate reports, select goal strate- 
gies, select performance metrics, select the goals for the 
pools, define the goal states, modify the effort map and 
routing tables, and create and modify enterprise parameters. 
Users access online interface 134 by using browser 136 to 
access Internet 138 to reach a specific web address. Once at 
the specific web address, the users enter the appropriate 
passwords to gain access to onUne interface 134. 

[0073] Although the embodiment shown in FIG. 1 con- 
tains more than one dialing device, in alternative embodi- 
ments distribution module 102 interfaces with a single 
dialing device. A single dialing device interfacing with 
distribution module 102 allows for variable control over 
similar lists of call records. For instance, call records may be 
divided into geographies such as states or time zones. 
Calling can be stopped automatically by distribution module 
102 when a quota is reached for a particular geography. 
Distribution module 102 presents the similar lists of call 
records for different geographies as different pools but the 
similar lists of call records for different geographies would 
represent one calling job within the single dialing device. 

[0074] FIG. 2 illustrates a block diagram of system 150 
employing two distribution modules in an alternative 
embodiment of the present invention. System 100 as shown 
in FIG. 2 is shown with less detail than in FIG. 1, 

[0075] System 150 employs two distribution modules 102 
and 152. Distribution module 152 is associated with two call 
centers 154 and 156. Call centers 154 and 156 each have one 
dialing device 158. Distribution module 152 provides the 
same functionality to call centers 154 and 156 that distri- 
bution module 102 provides to call centers 104 as described 
above in the discussion regarding FIG. 1. 

[0076] Distribution module 152 provides redundancy and 
prevents distribution module 102 from being overburdened 
by too many dialing devices. Distribution module 102 
functions effectively with more than one dialing device 
interfaced with it but performance and efiSciency suffers 
when too many dialing devices arc attached. Therefore, 
additional distribution module 152 allows for both it and 
distribution module 102 to achieve optimal performance and 
efficiency when adding additional call centers 154 and 156 
with additional dialing devices 158. 

[0077] In system 150, distribution modules 102 and 152 
are in communication with each other including communi- 
cating which call records are in the pools and the call attempt 
residts. Distribution modules 102 and 152 transfer call 
records and call attempt results between themselves just as 
distribution module 102 transfers call records and call 
attempt results between dialing devices 108. Therefore, if 
dialing devices 158 are idle while dialing devices 108 are 
overburdened, distribution module 102 transfers call records 
to distribution module 152 for dialing devices 158 to call. In 
addition, if distribution module 152 experiences an outage, 
distribution module 102 transfers the high priority calls from 



distribution module 152 to dialing devices 108 without 
worry of calling the same call record a second time in the 
same day when the first call restJted in a right parly contact. 

[0078] The two distribution modules 102 and 152 of 
system 150 also each include a goal module 103 and 153. 
Goal module 153 provides the same functionality to call 
centers 154 and 156 that goal module 103 provides to call 
centers 104 as described above in the discussion regarding 
FIG. 1. Goal modules 103 and 153 are in communication 
with each other including communicating the performance 
of their respective pools and queues. Through the use of 
distribution modules 102 and 152, goal modules 103 and 
153 can transfer levels of effort between their respective 
pools just as goal module 103 transfers levels of effort 
between pools 128. Therefore if high priority pools 128 are 
not meeting their goals, then goal module 153 can transfer 
levels of effort from distribution module 152 so that the high 
priority pools 128 will achieve their goals. 

[0079] Referring now to FIG. 3, a flow diagram depicts a 
process for distributing outbound call records. The process 
begins at step 170 with the transfer of call records from host 
112, dialing devices 108, or scheduling module 122 to 
distribution module 102. In step 172, distribution module 
102 organizes and arranges the call records into pools 128. 
Based upon user inputs distribution module 102 assigns 
queues 130 to specific dialing devices in step 174. 

[0080] In step 176, distribution module 102 checks to see 
if the selection mles are to be applied to pools 128 and 
queues 130. If the selection rules are not to be appHed, then 
the process continues in step 178. If selection rules are to be 
applied, then in step 180 distribution module 102 determines 
if priority, percentage, or quota rules are applied to pools 
128. If priority rules are applied, then in step 182 distribution 
module 102 applies the priority rules to pools 128 and 
queues 130 and the process continues on to step 178. If 
percentage rules are applied, then in step 184 distribution 
module 102 applies the percentage rules to pools 128 and 
queues 130 and the process continues in step 178. If the 
quota rules are applied, then in step 186 distribution module 
102 applies the quotas to pools 128 and queues 130 and the 
process continues to step 178. 

[0081] Distribution module 102 then deUvers enough call 
records to queues 130 for dialing devices 108 to place 
telephone calls for fifteen, thirty, sixty minutes, or an appro- 
priate amount of time to place calls in step 178. In step 190, 
distribution module 102 locks the call records assigned to 
dialing devices 108 and creates a contingency file specific 
for each dialing device 108 in step 192. 

[0082] In step 194, distribution module 102 transfers 
queues 130 containing the set number of call records to 
dialing devices 108. Periodically, distribution module 102 
uploads call record statistics from each queue 130 in step 
196. Distribution module 102 may upload the call record 
statistics from queues 130 every few seconds, every few 
minutes, every hour, or any other appropriate interval of 
time. Call record statistics include such information as how 
many call records remain to be called and the rate at which 
dialing devices 108 are depleting the call records in queues 
130. In addition to uploading caU record statistics, in step 
198 distribution module 102 also uploads call attempt 
results. Call attempt results include whether a right party 
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contact or wrong party contact was made or whether an 
answering machine was reached when dialing devices 108 
place a telephone call. 

[0083] Id step 202 distribution module 102 updates the 
contingency file with the call attempt results ^ecific for 
dialing devices 108. In step 204, distribution module 102 
uses the caU record statistics gathered in step 196 to analyze 
the number of call records remaining to be called and the 
depletion rate of the call records within queues 130, Based 
upon the call attempt results, distribution module 102 re- 
presents to pools 128 call records where the first attempt to 
make a right party contact was unsuccessful so that the call 
record can be called later in the day in step 206. In addition, 
the call record can be made unavailable for the remainder of 
the day if a right party contact was made. 

[0084] Based upon the call record statistics, distribution 
module 102 determines in step 208 if more call records need 
to be sent from pools 128 to queues 130. If more call records 
are needed, then in step 210 distribution module 102 sends 
additional call records from pools 128 to queues 130 and the 
process repeats beginning with step 176 until manually 
stopped. But if distribution module 102 determines that no 
additional call records need to be sent from pools 128 to 
queues 130 in step 208, then the process repeats beginning 
with step 196 until manually stopped or until there are no 
call records remaining to be called. 

[0085] FIGS. 4a and 46 illustrate a flow diagram for the 
population of pools 128 and queues 130 with call records. 
The call records in FIGS, 4a and 4b include sdieduling 
information provided by scheduling module 122. 

[0086] Referring to FIG. 4a, in step 222 the call records 
pass through scheduling module 122 from either dialing 
devices 108 or host 112. Scheduling module 122 adds call 
scheduling information to each call record as it passes 
through it. In step 224, scheduling module 122 transfers the 
call records containing call scheduling information to call 
record database 118 within distribution module 102. Distri- 
bution module 102 then arranges the call records into pools 
128 in step 226. When distribution module 102 places the 
call records into pools 128, distribution module 102 exam- 
ines each call record to determine how to extract the 
scheduling information, accoimt number and telephone 
number fit>m the call record. In addition, distribution mod- 
ule 102 flags any caU records where the scheduling infor- 
mation or telephone number is stripped from the end of the 
call record before placing it in the pools 128. 

[0087] In step 228, distribution module 102 spUts the call 
records into a plurality of pools 128. Each pool 128 holds the 
call record as a data string and the call records are in the 
same format within pools 128. In addition, distribution 
module 102 arranges the call records within pools 128 so 
that each call record is selectable by its accotmt number. 

[0088] The call scheduling information provided by 
scheduling module 122 allows for an optimum order to call 
the call records. Using the call scheduling information, 
distribution module 102 creates hourly indices for pools 128 
in step 230. The hourly indices aUow for pools 128 to take 
advantage of the fact that the call order and call priority of 
each call record changes based upon the time of day. For 
example, a call record might be scheduled to be the first call 
at 8;00AM and if not successfully called at 8:00AM then 



rescheduled to be the tenth call made at 6:00PM. There is a 
hourly index created for each hour of the calling day and the 
hourly indices are shown in step 232. Distribution module 
102 creates an index for each hoiu" for each pool 128. 

[0089] In addition to the houriy indices, distribution mod- 
ule 102 also creates an immediate index and an overflow 
index. The immediate index contains call records that are 
always the first to be called at the beginning of every hourly 
index. The call records within the immediate index aUow 
real time call record insertion based upon previous call 
attempts and are often call records that resulted in no contact 
when called the first time. Call records contained in the 
overflow index are call records which were not scheduled to 
be called or call records that do not have call scheduling 
information. 

[0090] Once the call records are arranged into pools 128 
and the hourly indices are created, the process of transferring 
the call records from pools 128 to queues 130 begins. In step 
234, distribution module 102 selects the call records con- 
tained in the immediate index. Distribution module 102 also 
removes any caU records that are unavailable to be called 
and marks the call records as unavailable in step 236. In step 
238, distribution module 102 determines if it is ready to 
transfer the call records from pools 128 to queues 130 for 
this hour and if there are a sufficient number of call records 
to be transferred from the immediate index to allow for 
fifteen, thirty, sixty minutes, or an appropriate amoimt of 
time for calling. If there are sufficient call records, then in 
step 239, distribution module 102 transfers the call records 
from the pool immediate index to queues 130. 

[0091] If there are not enough caU records in the imme- 
diate index, then in step 240 distribution module 102 selects 
call records from the appropriate hourly index. These addi- 
tional caU records in combination with call records from the 
immediate index will allow for fifteen, thirty, sixty minutes, 
or an appropriate amount of time for calling. In step 242, 
distribution module 102 removes any call records unavail- 
able to be called and marks the call records as unavailable. 
Distribution module 102 then transfers the call records from 
the immediate index and the appropriate hourly index to 
queues 130 in step 239. 

[0092] In step 244, distribution module 102 transfers 
queues 130 containing the call records to dialing devices 
108. After queues 130 are transferred to dialing devices 108, 
in step 246 dialing devices 108 begin calling the call records. 

[0093] Referring to FIG. 4b, as dialing devices 108 call 
the call records, distribution module 102 monitors dialing 
devices 108 and queues 130 for when it is time to send the 
next hourly index of call records from pools 128 to queues 
130 in step 248. In determining when to send the next hourly 
index, distribution module 102 cannot start morning hour 
queues before the acmal hour of the hourly index and must 
stop evening hour queues before the hoiu^ly index hour 
expires. For instance, the pool morning hourly index for 
10:00AM cannot be sent from pools 128 to queues 130 
before 10:00AM and the evening hourly index for 7:00PM 
must stop calling at 8:00PM. This is in part to due to 
telemarketing regulations that regulate the times of day that 
telemarketing calls may be placed. 

[0094] If in step 248 it is time for the next houriy index, 
then in step 250 distribution module 102 selects the next 
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hourly index to be called and begins the process of trans- 
ferring the call records from the appropriate hourly index to 
queues 130. The process of selecting the next hourly index 
repeats steps 234 through 244 by first taking call records 
from the immediate index and adding call records from the 
appropriate hourly index as explained above. 

[0095] If in step 248 it is not time for the next hour, then 
distribution module 102 determines queue depth and the 
time to go in step 252. Queue depth is the amount of call 
records remaining to be called in the queue while time to go 
is the amount of time remaining in the hour for the hourly 
index. In step 254 if the depth is not too low and the time to 
go is not too short so that there are a sufficient amount of call 
records to call for the remaining time left in the hour, then 
additional call records are not needed in queue 130. So in 
step 256, the call attempt results regarding a right or wrong 
party contact are uploaded from dialing devices 108 and sent 
back to distribution module 102 in step 258. The process 
then returns to step 234 of FIG. 4a to begin the next record 
search. 

[0096] If in step 254 distribution module 102 determines 
that the depth is too low or the time to go is too short, then 
in step 260 distribution module 102 calculates the number of 
call records needed to finish out the hour for the hourly 
index. In step 262, distribution module 102 selects addi- 
tional caU records to call by repeating steps 234 through 239 
above and transferring the call records from the pools 128 to 
queues 130 in step 264 so that dialing devices 108 do not sit 
idle but finish out the hour placing telephone calls. The 
process then returns to step 234 of FIG. 4a to begin the next 
record search. 

[0097] FIG. 5 depicts a flow diagram of a method for 
goals based routing of contact records employing a meet- 
goals goal strategy. The method begins at step 300 when 
goal module 103 selects a performance metric for each pool 
128, determines a goal for each pool 128 and prioritizes 
pools 128 relative to each o±er. At step 302 goals module 
103 calculates a goal status for each pool 128 using the goal 
and performance metric for each pool 128. After goal 
module 103 has calculated a goal status, goal module 103 
cycles through pools 128 in descending priority order at step 
304. 

[0098] At step 306, goal module 103 selects a target pool 
based on its priority. Goal module 103 selects a target pool 
by first selecting the pool 128 having the highest priority. 
Goal module 103 then determines the goal state from the 
goal status for the target pool to determine if the target pool 
is behind goal at step 308. If the target pool is not behind 
goal, then at step 310 goal module 103 checks to see if there 
are additional pools 128 to cycle through. If there are not 
additional pools 128 to cycle through, then the process ends. 
But if there are additional pools 128 to cycle through at step 
310, then the process returns to step 306 where goal module 
103 selects the pool 128 having the next highest priority to 
determine if that target pool is behind goal. If that target pool 
is not behind goal, then the process repeats until either goal 
module 103 locates a target pool that is behind goal at step 
308 or the process ends because no target pools are behind 
goal. 

[0099] If at step 308, the target pool is behind goal, then 
goal module 103 cycles through donor pools from lowest to 
highest priority at step 312. The donor pools include all the 



other pools 128 except the target pool that was selected at 
step 308. At step 314, goal module 103 selects a donor pool 
128 having the lowest priority out of all the donor pools. The 
goal module 103 then determines if the selected donor pool 
is active and able to donate levels of effort to the target pool 
at step 316. A pool 128 is active when it is still transferring 
contact records to queues 130 and hasn't satisfied its final 
goal or quota. Goal module 103 examines the routing table 
for the selected donor pool to determine if the donor pool is 
able to donate levels of effort to the target pool. Since each 
pool 128 has its own routing table, goal module 103 must 
examine the routing table to determine if the donor pool is 
able to donate any levels of effort. Generally, if the selected 
donor pool is ahead of goal or at goal, it is able to donate a 
percentage of level of effort to the target pool regardless of 
the respective pool priorities. If the donor pool is behind 
goal but the target pool is of a higher priority, then generally 
the donor pool is available to donate some percentage of 
level of effort. If the donor pool is behind goal and the target 
pool is of the same priority or lower priority, then typically 
the donor pool is not able to donate any level of effort to the 
target pool. 

[0100] If at step 316 the donor pool is both active and able 
to donate a percentage of level of effort to the target pool, 
then at step 318 goal module 103 transfers a percentage of 
the level of effort from the donor pool to the target pool. 
Goal module 103 transfers the level of effort from the donor 
pool to the target pool by modifying the effort map in 
accordance with the limits specified in the routing table for 
the donor pool. To donate the level of effort from the donor 
pool to the target pool, goal module 103 examines the 
routing table for the donor pool to determine how much level 
of effort may be donated from the donor pool to the target 
pool. For instance using the example routing table in Table 
3, if the target pool is of a higher priority than the donor pool 
and the donor pool is above its goal, then goal module 103 
transfers 75% of the level of effort for the donor pool to the 
target pool. Therefore, if pool 128fl is the donor pool and 
pool 128c is the target pool, goal module 103 transfers 75% 
of the level of effort for pool 128a to pool 128c thereby 
allowing queue 130fl to receive 25% of its contact records 
from pool 128a and 75% of its contact records from pool 
128c instead of queue 130^ receiving 100% of its contact 
records from pool 128fl. Pool 128c now supplies contact 
records to queues 130a and 130^ instead of jiist queue IZOd 
which allows additional agents 110 to access contact records 
from pool 128c and thereby meet the goal for pool 128c. 
Goal module 103 then modifies the effort map to reflect this 
change in the levels of effort between pools 128. 

[0101] After goal module 103 transfers the level of effort, 
at step 320 goal module 103 determines if there are addi- 
tional donor pools to cycle through. If there are additional 
donor pools to cycle through, then the process reniras to step 
314 where goal module 103 selects the donor pool having 
the second lowest priority and the process repeats until there 
are no more donor pools to cycle through at step 320. If at 
step 316 the donor pool is either not active or not able to 
donate a percentage of level of effort to the target pool, the 
process proceeds to step 320 where goal module 103 deter- 
mines if there are additional donor pools to cycle through as 
described above. 

[0102] When at step 320 goal module 103 determines that 
there are no more donor pools to cycle through, the process 
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proceeds to step 310 where goal module 103 determines if 
there are any additional pools 128 to cycle through. If there 
are no more pools 128, then the process ends. If there are 
additional pools, then the process returns to step 306 where 
goal modiile 103 selects the next pool 128 based on its 
priority to determine if it is behind its goal. 

[0103] The method of FIG. 5 repeats until goal module 
103 has chedced every pool 128 from highest to lowest 
priority to see if pools 128 are behind goal. Therefore, the 
pools 128 having the highest priority are addressed first by 
goal module 103 ensuring that pools 128 having the highest 
priority shall achieve and/or maintain their goals by trans- 
ferring levels of effort away from pools 128 having a lower 
priority to pools 128 having a higher priority. 

[0104] FIG. 6 illustrates a flow diagram of a method for 
goals based routing of contact records employing an exceed- 
goals goal strategy. The method begins at step 330 when 
goal modtde 103 selects a performance metric for each pool 
128, determines a goal for each pool 128 and prioritizes 
pools 128 relative to each other At step 332, goal module 
103 calculates a goal status for each pool 128 using the goal 
and performance metric for each pool 128. After goal 
module 103 has calculated a goal status, goal module 103 
cycles through pools 128 in an ascending priority order at 
step 334. 

[0105] At step 336, goal module 103 selects a target pool 
based on its priority. Goal module 103 selects a target pool 
by first selecting the pool 128 having the lowest priority. 
Goal module 103 then determines the goal state using the 
goal status for target pool to determine if target pool is 
behind goal at step 338. If target pool is not behind goal, then 
at step 340 goal module 103 checks to see if there are 
additional pools 128 to cycle through. If there are no 
additional pools 128 to cycle through, the process ends. But 
if there are additional pools 128 to cycle through at step 340, 
then the process returns to step 336 where goal module 103 
selects the pool 128 having the next lowest priority to 
determine if that target pool is behind goal. If that target pool 
is not behind goal, then the process repeats until either goal 
module 103 locates a target pool that is behind goal at step 
338 or the process ends because no target pools are behind 
goal. 

[0106] If al step 338, the target pool is behind goal, then 
goal module 103 cycles through recipient pools fi-om highest 
to lowest priority at step 342. The recipient pools include all 
the other pools 128 except the target pool that was selected 
at step 336. At step 344, goal module 103 selects a recipient 
pool having the highest priority out of all the recipient pools. 
Goal module 103 then determines if the selected recipient 
pool is active and ahead of its goal at step 346. A pool 128 
is active when it is still transferring contact records to queues 
130 and has not satisfied its final goal or quota. 

[0107] If at step 346 the recipient pool is both active and 
ahead of its goal, then at step 348 goal module 103 transfers 
a percentage of the level of effort &om the target pool to the 
recipient pool. After goal module 103 transfers the level of 
effort, at step 340 goal module 103 determines if there are 
additional pools 128 to cycle through. If there are no 
additional pools 128 to cycle through at step 340, then the 
process ends. But if at step 340 there are additional pools 
128 to cycle through, then the process returns to step 336 
where goal module 103 selects the target pool having the 
next lowest priority, 

[0108] If at step 346 the recipient pool is either not active 
or not ahead of goal, the process proceeds to step 350 where 



goal module 103 determines if there are additional recipient 
pools to cycle through. If there are additional recipient pools 
to cycle through at step 350, then the process returns to step 
344 where goal module 103 selects a recipient pool having 
the next highest priority and the process repeats as described 
above. 

[O109] If at step 350 there are no more recipient pools to 
cycle through, the process continues to step 352. The method 
only proceeds to step 352 after goal module 103 has exam- 
ined all of the recipient pools to determine if the recipient 
pools are active and ahead of goal. At step 352, goal module 
103 cycles through recipient pools from highest to lowest 
priority and at step 354 goal module 103 selects the recipient 
pool having the highest priority. Al step 356, goal module 
103 determines if the selected recipient pool is active and at 
goal. If the selected recipient pool is active and at goal, then 
at step 358 goal module 103 transfers a percentage of the 
level of effort from the target pool to the selected recipient 
pool. The process then continues on to step 340 where goal 
module 103 determines if there are additional pools 128 to 
cycle through and the process either ends or returns to step 
336. 

[0110] If at step 356 goal module 103 determines that the 
selected recipient pool is either not active or not at goal, then 
at step 360 goal module 103 determines if there are addi- 
tional recipient pools to cycle through. If there are not 
additional recipient pools to cycle through, then the process 
continues to step 340 where goal module 103 determines if 
there are additional pools 128 to cycle through as described 
above. If there are additional recipient pools to cycle through 
at step 360, then the process returns to step 354 where goal 
module 103 selects the next recipient pool having the next 
highest priority and the process repeats as described above. 

[OIU] The method of FIG, 6 repeats until goal module 
103 has checked every pool 128 from lowest to highest 
priority to see if pools 128 are behind goal. Therefore, the 
pools 128 having the lowest priority are examined first to 
determine if they are able to donate a percentage of level of 
effort to pools 128 having higher priority so that the pools 
128 having the highest priority exceed their goals. 

[0112] In an alternate embodiment, the present invention 
applies to the different types of contacts records and devices 
listed above and manages other types of customer contact 
requests such as inbound calls, email, Internet chat, online 
requests for live chat in addition to outbound call records. 

[0113] Although the present invention has been described 
in detail, it should be understood that various changes, 
substitution, and alterations can be made hereto without 
parting from the spirit and scope of the invention as defined 
by the appended claims. 

What is claimed is: 

1. A system for distributing contact records utilizing 
preemptive goals based routing, the system comprising: 

a plurality of devices operable to receive a plurality of 
contact records and to provide a plurality of contact 
records to one or more agents; 

a distribution module interfaced with the pltirality of 
devices and including a plurality of pools and a plu- 
rality of queues, the distribution module operable to 
place the contact records into the pools, transfer less 
than all of the contact records from the pools to the 
queues, and transfer the queues to the devices; and 
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a goal module interfaced with the distribution module, the 
goal module operable to monitor the performance of 
the pools and modify which queues the pools transfer 
contact records to based on the performance of the 
pools. 

2. The system of claim 1 wherein the goal module 
organizes the agents into one or more teams. 

3. The system of claim 1 further comprising one or more 
performance metrics associated with the pools, the perfor- 
mance metric operable to determine how to measure the 
performance of the pools. 

4. The system of claim 3 wherein the goal module selects 
the performance metric for each pool. 

5. The system of claim 3 wherein a user selects the 
performance metric for each pool. 

6. The system of claim 1 wherein the goal module 
modifies which queues the pools transfer contact records to 
by transferring queues away from one or more pools having 
unsatisfactory performance. 

7. The system of claim 1 wherein the goal module 
modifies which queues the pools transfer contact records to 
by transferring queues to one or more pools having unsat- 
isfactory performance. 

8. The system of claim 1 further comprising one or more 
goal strategies associated with the goal module, ±e goal 
strategies operable to control how the goal module modifies 
which queues the pools transfer contact records to based on 
the performance of the pools. 

9. The system of claim 1 wherein the goal module 
identifies a final goal for each pool. 

10. The system of claim 9 wherein when a pool satisfies 
the final goal for that pool, the goal module transfers the 
queues from the pool satisfying the final goal to one or more 
pools not satisfying the final goals. 

U. The system of claim 1 wherein the goal module 
prioritizes the poob relative to each other. 

12. The system of claim 1 wherein the goal module 
determines one or more goals and one or more gpal states for 
each pool, the goal state operable to indicate the perfor- 
mance of the pools relative to the goals. 

13. The system of claim 12 wherein the goal module 
modifies which queues the pools transfer contact records to 
based on the goal states for each pool. 

14. The system of claim 1 wherein the goal module 
defines one or more levels of effort for each queue, the levels 
of effort operable to determine the nmnber of agents that 
access contact records from a particular pool. 

15. The system of claim 14 wherein the goal module 
modifies which queues the pools transfer contact records to 
by transferring levels of effort between the pools. 

16. A system for distributing contact records utilizing 
preemptive goals based routing, the system comprising: 

a plurality of devices operable to receive a pliu-ality of 
contact records and to provide a pluraUty of contact 
records to one or more agents; 

a distribution module interfaced with the plurality of 
devices and including a plurality of pools and a plu- 
rality of queues, the distribution module operable to 
place the contact records into the pools, transfer less 
than all of the contact records from the pools to the 
queues, and transfer the queues to the devices; and 

a goal module interfaced with the distribution module, the 
goal module operable to define one or more levels of 



effort for each queue, determine a goal for each pool, 
determine a goal state for each pool, and modify which 
queues the pools transfer contact records to. 

17. The system of claim 16 wherein the goal state for a 
particular pool indicates whether the particular pool satisfies 
the goal. 

18. The system of claim 16 further comprising one or 
more performance metrics associated with the pools, the 
performance metric operable to determine how to measure 
the performance of the pools. 

19. The system of claim 18 wherein the goal module 
selects the performance metric for each pool. 

20. The system of claim 16 wherein the goal module 
calculates a goal status for each pool. 

21. The system of claim 16 wherein the goal module 
identifies a final goal for each pool. 

22. The system of claim 21 wherein when a pool satisfies 
the final goal for that pool, the goal module transfers the 
level of effort from the pool satisfying the final goal to one 
or more pools not satisfying the final goals. 

23. The system of claim 16 wherein the goal module 
prioritizes the pools relative to each other. 

24. The system of claim 16 wherein the goal module 
modifies which queues the pools transfer contact records to 
based on the gpal states for each pool. 

25. The system of claim 16 wherein the goal module 
modifies which queues the pools transfer contact records to 
by transferring levels of effort between the pools. 

26. The system of claim 25 wherein the goal module 
transfers levels of effort to one or more pools not satisfying 
the goals. 

27. The system of claim 25 wherein the goal module 
transfers levels of effort away from one or more pools not 
satisfying the goals. 

28. TTie system of claim 16 further comprising one or 
more goal strategies associated with the goal module, the 
goal strategies operable to control which levels of effort are 
transferred between the pools. 

29. The system of claim 28 wherein the goal module 
modifies ^^^ch queues the pools transfer contact records to 
based on the goal states for each pool and a selected goal 
strategy. 

30. The system of claim 16 wherein the goal module sets 
a limit on the level of effort that may be transferred away 
from each pool to the other pools. 

31. The system of claim 16 further comprising an effort 
map associated with the goal module, the effort map oper- 
able to identify the pools from which the queues and agents 
receive contact records and to identify the levels of effort for 
each pool. 

32. The system of claim 31 further comprising one or 
more routing tables associated with the pools and the effort 
map, the routing tables operable to determine how the goal 
module transfers levels of effort between the pools based on 
the goal states for each pool 

33. A method for preemptive goals based routing of 
contact records, the method comprising: 

organizing a plurality of contact records into a plurality of 
pools; 

transferring less than all of the contact records from the 
pools to a pluraUty of queues; 

transferring the queues to a plurality of devices and a 
plurahty of agents; 
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monitoring the performance of the pools; and 

modifying the queues to which the pools transfer contact 
records to based on the performance of the pools. 

34. The method of claim 33 further comprising organizing 
the agents into one or more teams. 

35. The method of claim 33 >\^erein monitoring the 
performance of the pools comprises determining how to 
measure the performance of each pool. 

36. The method of claim 35 wherein determining how to 
measure the performance of the pools comprises selecting a 
performance metric for each pool. 

37. The method of claim 33 wherein monitoring the 
performance of the pools comprises establishing a final goal 
for each pool. 

38. The method of claim 37 wherein modifying the 
queues to which the pools transfer contact records to com- 
prises transferring one or more of the queues from a pool 
satisfying the final goal to one or more of pools not satis- 
fying the final goal. 

39. The method of claim 33 wherein modifying the 
queues to which the pools transfers contact records to 
comprises transferring additional contact records from one 
or more pools having satisfactory performance to the 
queues. 

40. The method of claim 33 wherein modifying the 
queues to which the pools transfers contact records to 
comprises transferring additional contact records from one 
or more pools having unsatisfactory performance to the 
queues. 

41. The method of claim 33 \^^erein monitoring the 
performance of the pools comprises cycling through the 
pools to locate a pool having unsatisfactory performance. 

42. The method of claim 41 wherein cycling through the 
pools to locate a pool having unsatisfactory performance 
comprises selecting the pool having the unsatisfactory per- 
formance. 

43. The method of claim 41 wherein modifying the 
queues to which the pools transfers contact records to 
comprises transferring the queues away from the pool hav- 
ing unsatisfactory performance. 

44. The method of claim 41 wherein modifying the 
queues to which the pools transfers contact records to 
comprises transferring the queues to the pool having imsat- 
isfactory performance. 

45. The method of claim 33 wherein organizing the 
contact records into a plurality of pools comprises prioritiz- 
ing the pools relative to each other. 

46. The method of claim 33 wherein modifying the 
queues to which the pools transfer contact records to com- 
prises controlling which queues are transferred between the 
pools. 

47. A method for preemptive goals based routing of 
contact records, the method comprising: 

organizing a plurality of contact records into a plurality of 
pools; 

determining a goal for each pool; 

transferring less than all of the contact records from the 
pools to a plurality of queues, each queue including one 
or more levels of eflfort; 

transferring the queues to a plurality of devices and a 
plurality of agents; 



determining a goal state for each pool; and 

modifying the queues to which the pools transfer contact 
records to based on the goal states for each pool. 

48. The method of claim 47 wherein determining a goal 
for each pool comprises determining how to measure the 
performance of each pool. 

49. The method of claim 48 wherein determining how to 
measure the performance of the pools comprises selecting a 
performance metric for each pool. 

50. The method of claim 47 further comprising calculat- 
ing a goal status for each pool. 

51. The method of claim 47 wherein determining a goal 
for each pool comprises establishing a final goal for each 
pool. 

52. The method of claim 51 wherein modifying the 
queues to which the pools transfer contact records to com- 
prises transferring the level of efEort from a pool satisfying 
the final goal to one or more of pools not satisfying the final 
goal. 

53. The method of claim 47 wherein organizing the 
contact records into a plurality of pools comprises prioritiz- 
ing the pools relative to each other. 

54. The method of claim 47 wherein modifying the 
queues to which the pools transfer contact records to com- 
prises transferring the levels of effort between the pools. 

55. The method of claim 54 wherein transferring the 
levels of effort between the pools comprises determining the 
pools that receive the levels of effort from the other pools 
and the pools that transfer levels of effort to the other pools. 

56. The method of claim 54 wherein transferring the 
levels of effort between the pools comprises transferring the 
levels of effort to one or more pools not satisfying the goals, 

57. The method of claim 54 wherein transferring the 
levels of effort between the pools comprises transferring the 
levels of effort away from one or more pools not satisfying 
the goals. 

58. The method of claim 54 wherein transferring the 
levels of effort between the pools comprises limiting the 
levels of effort that may be transferred from a particular pool 
to a different pool based upon the goal state of the particular 
pool. 

59. The method of claim 47 wherein determining a goal 
state for each pool comprises determining if the pools are 
satisfying the goals. 

60. The method of claim 47 wherein determining a goal 
state for each pool comprises cycUng through the pools to 
locate a pool having a desired goal state, 

61. The method of claim 60 wherein cycling through the 
pools to locate a pool having a desired goal state comprising 
selecting the pool having the desired goal state. 

62. The method of claim 61 wherein modffying the 
queues to which the pools transfer contact records to com- 
prises transferring levels of effort away from the pool having 
the desired goal state. 

63. The method of claim 61 wherein modifying the 
queues to which the pools transfer contact records to com- 
prises transferring levels of effort to the pool having the 
desired goal state. 
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